This chapter is for advanced users and administrators only. In most situations the CommuniGate Server uses the default rules to route messages, and you should not worry about routing. Only if your system is working as a message relay for other systems, or if you want to use sophisticated routing schemes, you should read this chapter.
When the Server processes messages, it extracts the information about recipients and routes the messages to users and/or modules. This is done by the part of the Server called Router.
Each e-mail address can be divided into so-called "domain name" and "local" strings. Usually, an e-mail address looks like xxxx@yyyyy, where yyyy is the "domain name" (the address of the system) and xxxx is "local" part, i.e. a user account name in that system.
E-mail address can more complicated, for example they can include the "path" information:
<@zzzz: xxxx@yyyyy> or xxxx%yyyy@zzzz
Such addresses require a message to be sent to the system zzzz first, and then that system should deliver it to xxxx@yyyy.
When the Router parses an address, it extracts the name of the system the message should be delivered to. It becomes the "Domain" part of the address. The rest of the address is places into the "Local" part, i.e. the "Local" part defines the recipient when the message is delivered to the "Domain" system. In the example above, the Domain part is "zzzz", while the "Local" part is "xxxx@yyyy"
See the RFC822 and related documents for details on e-mail address formats.
Converting to the E-mail Address Type
As explained in the Addresses chapter, addresses in the CommuniGate system have various service types. The E-mail type is a special, built-in service type. You use the e-mail type addresses to send messages via various flavors of electronic mail, while you use fax-type addresses to send faxes, pager-type addresses to send page messages, etc. Inside the CommuniGate Server all addresses are converted to the E-mail type first.
To convert a non-E-mail address, the Router adds the '@' sign and the service module name to the address body. For example, a fax address (i.e. the address with FaxGate service type) with the body 4155551212 will be converted to the e-mail address 4155551212@FaxGate.
Extracting the Domain And Local Parts
After an address is converted to the E-mail type, that address is parsed and the "domain" and "local" parts are extracted. Since E-mail addresses can contain comments, comments are removed when the system parses an address.
When the domain name is extracted from an address, the Router compares it against the domain name of the CommuniGate Server. If they match, the domain name is set to an empty string. Since the local part can be not only a user name, but an e-mail address again, the Router starts processing again, i.e. it tries to divide the current local part into the domain and local parts.
For example, if the domain name of your CommuniGate Server is stalker.com, then the addresses from the above example will be converted to:
When the domain part is extracted, and it is not the Domain Name of the Server, the Router first checks the routing records in the Routing&Aliasing table. This table is initially empty, but you can put records in it using the Router command in the CommuniGator application. You should have the "can configure services" privilege to modify the Routing&Aliasing table.
Each line in the Routing&Aliasing Table is a routing record and contains a domain name and the routing path for that domain. If the domain name exists in the Routing table, it is substituted with the "routing path", and the Router restarts searching using the new domain name.
Example:
hq.stalker.com = twisted.stalker.com
All messages directed to the domain named hq.stalker.com will be redirected to the domain twisted.stalker.com. The Router restarts, trying to find a path to deliver messages to twisted.stalker.com.
The routing path can specify non-E-mail address type, for example:
hq.stalker.com = <UUCPGate>twisted
This situation is very rare, and its usage is not described here.
Note: the semicolon symbol (;) can be used in the Routing&Aliasing table to place comments: the symbol itself and all symbols after it on the same line are ignored when the table is processed.
If you have one or several e-mail gateways installed, you may want to specify the routing information for the messages going through your Server to other systems. For example, if you use the UUCPGate module and want to provide e-mail access to Internet for several other systems connected to yours via UUCP links, you should specify the routing information. When your Server gets some mail for those systems from the Internet, it will know to which UUCP link it should route the mail. Since the UUCPGate module accepts domains like xxxx.uucp where xxxx is the UUCP system name (link), you may want to add the following lines to route the mail to neighbor1.com (uucp host name "neib1") and neighbor2.com (uucp host name "neib2"):
neighbor1.com = neib1.uucp
neighbor2.com = neib2.uucp
If the neighbor3.com system gets mail through the neighbor1.com system, you should add the following line:
neighbor3.com = neighbor3.com@neib1.uucp
Or, if you the neighbor1.com system cannot route the messages itself, and the uucp host name of neighbor3.com is neib3, you can specify the routing path explicitly:
neighbor3.com = neib1.uucp!neib3
If mail to several domains should be routed in the same or similar way, you may use the asterisk sign as the wild-card symbol:
*.hiscompany.com = hisnewcompany.com
In this case messages to all the domains ending with .hiscompany.com will be routed to the domain hisnewcompany.com.
The asterisk symbol can be used in the route path, in this case it is substituted with the symbols matching the wildcard symbol:
*.hiscompany.com = *.hisnewcompany.com
When such a routing line is entered and a message comes for the domain xxxx.hiscompany.com, that message is routed to xxx.hisnewcompany.com.
This method is very useful if you have several systems connected via UUCP links. You can give each system a domain name xxxxx.public.mycompany.com, where xxxxx is the same as the uucp name of that system. In this case, routing for all those systems can be defined with one routing line:
*.public.mycompany.com = *.uucp
Aliasing Table
If the domain part extracted is empty, it indicates that the message should be delivered to some "local user" whose name is specified in the Local part. In this case the Router checks the aliasing records in the Routing&Aliasing table.
Each aliasing record in the Routing&Aliasing Table contains a user name in the angle brackets and the routing path for that name. If the Local part matches a user name in some aliasing record, the routing path is taken and routing search restarts from the very beginning.
For example, if your company domain is mycompany.com and the user Bill is responsible for processing sales messages, you can enter the following line:
<sales> = Bill
in this case, all messages to sales@mycompany.com will go to Bill, as if they were sent to Bill@mycompany.com
If Bill uses a different server with the domain name hq.mycompany.com, then you can create the following alias:
<sales> = Bill@hq.mycompany.com
All messages directed to sales will be directed to Bill@hq.mycompany.com. The Router takes the new address, then it extracts the domain (hq.mycompany.com) and local (Bill) parts, then restarts trying to find a route to hq.mycomany.com.
Routing To Modules by Name
If the Domain part is not found in the Routing table, the Router checks if the domain part is actually the name of one of the communication modules installed. If it finds a module with that name, the message is routed to that module.
This method allows to simplify processing of non-E-mail addresses: when the fax address 5557771212 is processed by the Router, it is converted to the E-mail address 5557771212@FaxGate. If no routing is defined for the FaxGate domain, the Router finds the communication module by name, i.e. it routes the message to the FaxGate module.
Routing To Modules by Modules
After checking the domain name against the module names, the Router calls each communication module requesting a "route search". Both the domain and local parts are passed to each module. If a module detects that it can deliver a message to that address, the message is routed to that module.
Example: the address "666-777-8999"@Fax has been parsed, "666-777-8999" is the Local part, and Fax is the Domain part. This pair of strings (Fax and "666-777-8999") has been passed to the FaxGate module, which accepts all messages routed to the "Fax" domain. The FaxGate module informs the Router that it can process such an address, and the Router routes the message to the FaxGate communication module.
Some modules can modify the domain part string without asking the Router to route the message to them.
Example: the uucp host name of your system is ustalker. A message has been sent from some other host using the uucp addressing method. The address used was ustalker!hq.stalker.com!Susan. The address is parsed, the extracted parts are: Local part -Susan@hq.stalker.com, the Domain part - ustalker. When this string pair is passed to the UUCPGate, it detects that the message has been already delivered to the address specified in the domain part (because ustalker is the uucp host name of your system), so the module puts an empty string into the Domain part. But this does not mean that this module should deliver this message, so it does not ask the Router to route that address to the UUCPGate. As a result, the Router will see the empty Domain part and it will restart routing process using the Local part: Susan@hq.stalker.com
When the Domain part is empty, the Local part is supposed to be a user name on this server. If no alias record for the Local part is found, the built-in LocalGate module accepts the address: it checks if the Local Part specifies a user registered with the CommuniGate Server and places the message into the In Box of that user.
Building the Routing Information
When all the steps above are done, the Router knows to which communication module it should route a message. It calls that module and requests the routing information to be built. The module converts the address into the form it needs: for example, the FaxGate module converts the Local Part into the "canonical" phone number string. The routing information built is stored, and it can be used by the module when it is delivering the message.
Routing Failures
If all modules refuse to accept an address, routing fails. In addition, routing fails if some module reports an error when the address is passed to it for "routing search" or for "route building". Routing fails if a "loop" is detected in the Routing&Aliasing Table. Here is an example of a routing loop:
<sales> = Bill
<Bill> = sales
When routing fails, the message is routed to the local postmaster (if this option is switched on), and the notification message is created and sent back, informing the sender about the problem.
Routing non-E-mail Messages
As explained above, each address is first converted into an e-mail address.
For example, when a message has a fax address 101-555-1212, this address is first converted into an e-mail address: 1015551212@FaxGate. If there is no special routing for the domain "FaxGate" in the routing info, it is routed to the FaxGate module: the Domain part of that address - "FaxGate" matches the name of that module.
This means that if your server has FaxGate installed and receives an e-mail message addressed to 1015551212@FaxGate, this message will be routed to the FaxGate and sent to the phone number 101-555-1212. It also means that you can send a fax message via the Internet, i.e. your server can work as E-mail-to-fax gate: each message sent to nnnnnn%FaxGate@mycompany.com will be delivered to your server (mycompany.com) via Internet, then the server will route it to the FaxGate module, and it will fax the message to the phone number nnnnnn.
Since the addresses like nnnnnn%FaxGate@mycompany.com (other forms are <@mycompany.com:nnnnnn@FaxGate> and mycompany.com!FaxGate!nnnnnn) are not so easy to use, you may want to create a special domain for faxing over e-mail: fax.mycompany.com and then you should add a routing line:
fax.mycompany.com = FaxGate
Now you can use fax over e-mail by just sending messages to nnnnnnn@fax.mycompany.com
Aliasing is not limited to e-mail addresses. If all messages coming to user BigChief should be just sent as faxes to the international number 46(555)666-7777, enter the following line into the Routing&Aliasing Table:
<BigChief> = "+46(555)666-7777"@FaxGate
The same can be done with other modules as well: use PrintGate to print messages over Internet, etc.
On the other hand, routing can be used to provide services your own server does not support itself. If your server (mycompany.com) does not have a fax modem, but the server hq.mycompany.com has one, your users can still send faxes. Just add a routing line:
FaxGate = FaxGate@hq.mycompany.com
Since all fax addresses are first converted into E-mail addresses nnnn@FaxGate, the CommuniGate Server Router will route these messages as sent to nnnn%FaxGate@hq.mycompany.com. They will be delivered to the hq.mycompany.com server first, where they will be routed to the FaxGate module there and then they will be actually sent as faxes to the fax number nnnn.
